Direct Connectプライベート接続でS3へアクセスする高可用性な構成

コンニチハ、千葉です。

Direct Connect経由でS3エンドポイントにアクセスするにはDirect Connectのパブリック接続を利用する必要があります。

ただ、パブリック接続を使う場合、プロバイダが対応している必要があったり、グローバルIPが必要だったり、AWSエンドポイントのルーティングをオンプレ側のルータへ設定する必要があります。

そこで、もっとシンプルな構成としてDirect Connectのプライベート接続でS3へアクセスする、高可用性な構成を検証してみました。

構成

Internal ELBを構成し、AWS SDKやAWS CLIのプロキシとしてELBを指定します。

ELBには、httpプロキシ(squid)を組み込みます。httpプロキシサーバはS3エンドポイントへルーティングしS3へアクセスするように構成します。

可用性については、ELBを利用してhttpプロキシを冗長化することで確保しています。

また、オンプレ側でELBのFQDNを引ける必要があります。オンプレ側がパブリックなDNSへ接続可能な場合は問題ないのですが、 できない場合は、オンプレからAWSのDNSを引けるようにする必要があります。

以下構成のサマリです。

オンプレ側

• ELBの名前解決ができること
• AWS SDKまたはAWS CLIのプロキシ先をELBに設定

AWS側

• httpプロキシ(今回はsquid)を構成
• Internal ELBを構成し、httpプロキシを組み込む
• S3エンドポイントを構成

設定してみた

ELBの名前解決

オンプレ側でELBのFQDNを引ける必要があります。

オンプレ側でパブリックなDNSを参照できる場合は、ELBの名前解決が可能です(特に意識する必要なし)。しかし、パブリックなDNSにアクセスできない場合もあるかと思います。その場合は、こちらより、AWS環境のDNSを引くことが可能です。

httpプロキシ(今回はsquid)を構成

httpプロキシを構成します。今回はsquidをインストールして構成します。

インストール

# yum install squid
# chkconfig squid on
# service squid start

設定ファイルの変更

# vi /etc/squid/squid.conf

### アクセス許可するネットワークを指定(不要な行はコメントアウト)

 #acl localnet src 10.0.0.0/8	# RFC1918 possible internal network
 #acl localnet src 172.16.0.0/12	# RFC1918 possible internal network
 #acl localnet src 192.168.0.0/16	# RFC1918 possible internal network
 #acl localnet src fc00::/7       # RFC 4193 local private network range
 #acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines
 acl localnet src XXX.XXX.XXX.XXX/24

### プロキシするポートを指定(不要な行はコメントアウト)※80,443のみをプロキシする設定へ
 #acl Safe_ports port 21		# ftp
 #acl Safe_ports port 70		# gopher
 #acl Safe_ports port 210		# wais
 #acl Safe_ports port 1025-65535	# unregistered ports
 #acl Safe_ports port 280		# http-mgmt
 #acl Safe_ports port 488		# gss-http
 #acl Safe_ports port 591		# filemaker
 #acl Safe_ports port 777		# multiling http
 
### ホスト名の記述
visible_hostname unknown

設定変更したらsquidを再起動しておきます。今回は冗長構成のため2台構成しておきます。

ELBを構成し、httpプロキシを組み込む

ELBを作成します。ELBはInternal ELBとして構成し、オンプレからプライベートIPでアクセスするように構成します。

AWS SDKまたはAWS CLIのプロキシ先をELBに設定

AWS SDKまたは、AWS CLIのプロキシ設定を行います。

先ほど作成したELBのFQDNをプロキシに設定します。AWS CLIの場合は以下となります。

# export HTTPS_PROXY=internal-XXX.ap-northeast-1.elb.amazonaws.com:3128
# export HTTP_PROXY=internal-XXX.ap-northeast-1.elb.amazonaws.com:3128

S3エンドポイントを構成

S3エンドポイントを構成し、httpプロキシサーバがプライベート環境でもS3へアクセスできるように構成します。

動作確認

Direct Connect環境がないので、AWS上にオンプレVPC、AWSVPCを構成し擬似環境で確認してみました。

それでは、オンプレからS3へアクセスしてみます。

左：【オンプレ】S3アクセス、中：【AWS】httpプロキシ1アクセスログ、右【AWS】：httpプロキシ2アクセスログ

ファイルをアップロード

アップロード確認

プロキシ経由でのS3アクセスが可能であることを確認できました。

まとめ

Direct Connectのプライベート接続を利用して、S3へアクセスを行いました。Direct Connectを経由するので帯域を確保しつつ、さらに可用性も確保できました。もちろん、Direct Connect自体の冗長化も必要です。

[注意事項]
安定的なS3接続をするには、ELBのタイムアウトやEC2の帯域幅を考慮する必要があります。ELBのタイムアウトのチューニング、EC2インスタンスタイプによる帯域幅のチューニングも重要です。